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ABSTRACT 


Security  policies  define  how  information  within  a computer  system  is  to 
be  used.  Protection  mechanisms  are  built  into  these  systems  to  enforce  secu- 
rity policies.  However,  in  mo.-t  systems  it  is  quite  unclear  what  policies  a 
particular  mechanism  can  or  does  enforce.  This  paper  precisely  defines  secu- 
rity policies  and  protection  mechanisms  in  order  to  bridge  the  gap  between 
them  with  the  concept  of  soundness:  whether  a protection  mechanism  enforces 

a specific  policy  for  a given  program.  Different  sound  protection  mechanisms 


for  the  same  policy  and  program  can  then  be  compared  (on  the  basis  of  complete- 

. HrU 

ness)  to  determine  if  one  outperforms  the  others*''  Wc_a4-to-  show~th«t  (ftef  union 


of  mechanisms  for  the  same  policy  and  program  car.  be  taken  to  produce  a more 
complete  mechanism^  Although  a maximal  mechanism  exists  it  cannot  necessarily 
be  effectively  found. 


In  addition  to  developing  a theoretical  framework  in  which  to  discuss 

' lT  if.{  a 

securi ty  Jite.  introduce  Xhe  surveillance  protection  mechanism  a«d- -show-hoth 

^ 

that  it  is  sound  and  that  it  is  more  complete  than  tne  commonly  used  high 
A, 

water  mark  mechanism. 
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I.  INTRODUCTION 
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Within  computer  systems  we  distinguish  between  different  kinds  of  informa- 
tion based  on  a variety  of  reasons  (for  example,  privacy  of  individuals  which 
the  information  describes,  laws,  cost  of  theft);  in  addition,  we  wish  to  con- 
trol how  each  of  the  different  kinds  of  information  is  used.  This  problem  of 
information  control  is  analogous  to  one  ir.  society,  where  we  wish  to  control 
who  obtains  certain  information,  the  time  at  which  they  obtain  it  as  well  as 
which  of  their  subsequent  actions  are  influenced  by  having  the  information. 

Such  control  of  information  is  difficult  to  implement  in  society.  The  con- 
trol of  information  dissemination  has  proved  to  be  difficult  to  implement  in 
computer  systems  as  well  and  is  currently  the  subject  of  study  by  many  research- 
ers: [Bell  , [Jones  , [LampsonJt  [Popek],  [Schroeder],  [Walter],  [Weissman], 

[Wu If]. 

The  need  for  precise  and  complete  understanding  of  the  basic  questions  is 
mandatory.  To  illustrate  this,  compare  security  enforcement  flaws  to  compiler 
design  flaws.  When  a compiler  error  occurs,  the  users  complain  and  demand  cor- 
rection. On  the  other  hand,  when  a security  error  occurs,  the  violator  does 
not  disclose  the  system  flaw  that  allowed  him  to  perform  prohibited  actions. 
Often  in  the  case  of  information  theft,  no  trace  remains  to  show  that  one 
user  read  information  private  to  another.  For  these  reasons  precision  and 
proofs  are  not  a luxury,  but  a necessity. 

While  precision  and  proofs  are  required,  in  order  to  be  credible  the  basic 
framework  must  be  simple  and  clear.  No  one  will  believe  an  unstructured  sys- 
tem is  secure;  just  as  no  one  will  believe  that  a formal  proof  is  correct  if 

* 

A children's  tale  observes  that  if  one  person  knows  a secret,  it's  a secret, 
but  if  two  people  know  a secret,  it's  soon  public  knowledge. 
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it  is  too  long  or  poorly  structured.  The  proof  of  security  properties  of  a 
computer  system  is  especially  sensitive  to  this  issue  because  such  properties 
span  the  entire  system,  not  merely  a single  module  of  the  system.  We  conclude 
that  to  be  useful  the  basis  of  a theory  in  the  security  area  must  be  very  simple 
This  paper  presents  a framework  in  which  the  underlying  principles  of  secu- 
rity can  be  investigated.  We  believe  it  to  be  both  precise  and  yet  simple. 

The  basic  elements  of  our  theory  are:  a precise  definition  of  a security  policy 
of  information  control,  simple  enough  so  that  the  ramifications  of  the  policy 
are  clear,  and  a protection  mechanism  whose  purpose  is  to  'enforce'  a given 
security  policy.  Further,  we  relate  these  two  in  terms  of  soundness  and  com 
pie teness . These  terms  are  discussed  informally  below. 

A secu~ity  policy,  defining  what  information  is  to  be  protected,  has  a 
non-procedural  form.  The  definition  of  a protection  mechanism,  on  the  other 
hand,  is  procedural. 

A protection  mechanism  is  sound  provided  it  enforces  the  given  security 
policy.  Thus  soundness  is  the  bridge  between  the  non-procedural  security 
policy  and  the  procedural  protection  mechanism.  Currently  this  relation  is 
unclear  in  existing  security  systems.  When  a software  designer  is  asked  to 
define  the  security  policies  his  protection  mechanism  can  enforce  his  answer 
is  phrased  in  terms  of  a procedural  description  of  some  of  the  possible  state 
changes  of  his  mechanism.  Such  a description  is  insufficient.  A security 
policy  must  be  expressed  in  a language  such  that  the  policy's  author  i con- 
vinced it  is  what  he  intended. 

While  the  above  discussion  suggests  that  soundness  is  a binary  relation 
between  protection  mechanisms  and  security  policies,  such  is  not  the  case. 

It  also  depends  on  just  what  attributes  of  a program's  execution  are  observable, 


i.e.  visible  to  outside  observers.  For  example  an  outside  observer  may  or 
may  not  be  able  to  detect  the  running  time  of  a program's  execution.  Thus 
there  are  protection  mechanisms  which  are  sound  only  provided  running  time  is 
not  observable. 

Completeness  is  a measure  of  how  well  a given  protection  mechanism  per- 
forms. Sound  protection  mechanisms  abound;  the  key  is  to  find  those  that  are 
complete  in  that  the  ’ allow  the  user  to  do  as  much  as  possible.  The  impor- 
tance of  completeness  is  unclear  in  current  literature;  here  it  has  central 
importance . 

One  way  to  evaluate  a framework  such  as  the  one  developed  here  is  to  see 
what  results  have  come  as  a consequence  of  the  theory.  There  are  four  prin- 
cipal results.  First,  we  have  developed  a new  protection  mechanism  called 
the  surveillance  protection  mechanism.  Second,  we  can  faithfully  represent 
parts  of  actual  security  systems  in  this  framework.  Third,  we  can  show  that 
the  surveillance  mechanism  is  more  complete  than  several  other  existing  pro- 
tection mechanisms.  Fourth,  we  can  show  that  there  exists  a maximal  protec- 
tion mechanism.  Though  the  union  of  mechanisms  can  be  used  to  derive  increas- 
ingly powerful  mechanisms,  the  maximal  protection  mechanism  cannot  necessarily 
be  effectively  discovered. 

I 


II.  BASIC  MODEL 


. te  rst  concept  to  be  defined  is  the  concept  of  a computer  program. 
We  define  Q to  te  a program  provided 

Q:  r.x.  . . xD.  - E.x.  . . xE 
i k 1 n 

where  D.  is  the  Lange  of  the  ith  input  and  the  range  of  the  jth  output. 
Kx^,...,x^)  denotes  the  n-tuple  that  corresponds  to  the  input  (x^,.,.,x.) 

If  Q(x^,...,x^)  ■=  y, • ,yn  we  use  Q^x^ , . . . ,x^)  to  denote  y for  i from  1 
to  n. 


I 
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Programs  defined  here  can  be  viewed  in  many  different  ways.  A program 
could  be  a 'cosine'  subroutine  with  a single  input  parameter  , specifying 
an  angle  in  degrees,  and  a raal  valued  output  cos^).  Alternatively,  Q 
could  be  an  entire  user  job  (perhaps  composed  of  several  processes)  with 
inputs  x.j , . . . , x^  i which  are  files  and  input  x^  a stream  of  characters  from 

a terminal.  Output  could  then  be  the  files  , and  the  terminal 

output  yn-  An  important  feature,  therefore,  of  this  definition  of  program 
is  that  it  is  independent  of  any  particular  model  or  grain  of  computation. 

We  now  turn  our  attention  to  the  study  of  protection  mechanisms. 

PgilnlLjoU-  Suppose  that  Q:  D1x...xDk  - E]x...xEn  is  a program.  Then  M is  a 

protection  mechanism  for  Q provided  M:  D.x...xD,  - Elx.^xE’  and  E’  - E U F 

' k 1 n i i 

where  F is  disjoint  from  Et  for  all  i,  and  for  all  xk  and  1 Si  £ n 

Mi(x1,...,xk)  - Q1(x1 xk)  or  Mi(x1 x^  £ F. 
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The  set  F consists  of  the  violation  notices  of  M. 
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A protection  mechanism  acts  as  follows:  For  input  a and  for  each  i 

the  mechanism  decides  whether  or  not  to  give  the  output  value  Q^(a).  If  it 
decides  not  to  allow  this  output,  then  the  protection  mechanism  gives  a viola- 
tion notice  from  F.  The  key  constraint  on  the  protection  mechanism  M is  that 
it  must  act  simply  as  a "gatekeeper"  (see  Figure  1);  it  can  allow  the  normal 
output  or  an  output  from  F.  Intuitively  violation  notices,  i.e.,  elements 
from  F,  can  be  thought  of  as  alleged  attempted  violations.  The  definition  of 
protection  mechanism  is  quite  general  in  that  the  protection  mechanism  can 
decide  whether  or  not  to  output  Q(a),  based  on  any  criterion  at  all.  Note 
that  any  program  satisfying  these  constraints  is  a protection  mechanism.  We 
make  no  assumption  about  whether  it  executes,  interprets  or  even  simulates  the 
program  Q. 


•violation^  no 


-♦  output  Q(x1 x^) 


output  violation  notice(s) 


Figure  1.  A functional  view  of  a protection  mechanism  for  Q. 


| 
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More  concretely,  suppose  that  a user  submits  a job  to  a computer  system, 
and  then  waits  for  his  output  from  a line  printer  in  a batch  environment  or 
from  an  interactive  terminal  in  a time  sharing  environment.  In  an  unprotected 

"fc  a 

a denotes  a^,...,a^  the  actual  input  values  for  input  variables  x^,...,x^ 
respectively;  the  value  of  k will  always  be  clear  from  the  context. 
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computer  system  the  user  will  always  receive  Q(a),  that  is,  the  result  of 
his  computation.  In  a protected  computer  system  he  may  or  may  not  receive 
Q(a> : if  his  computations  violated  no  ’rules',  then  he  will  receive  Q(a) ; 

otherwise,  he  will  receive  a violation  notice. 

It  is  important,  to  note  that  M always  outputs  something.  This  restric- 
tion that  M be  total  is  an  entirely  practical  one.  In  any  real  computer  sys- 
tem, programs  are  never  allowed  to  run  forever.  Moreover,  at  the  cost  of 
some  complexity  in  our  theory  we  could  extend  the  concept  of  program  to  par- 
tial functions,  i.e.  to  programs  that  did  not  always  halt.  However,  the  cost 
seems  to  outweigh  the  advanta^  s;  therefore,  in  this  paper  all  programs  will 
be  assumed  to  be  total 

The  purpose  of  protection  mechanism  is  to  -control  information  flow'; 
in  our  framework  this  means  to  enforce  security  policies. 

Definition.  A security  policy  I for  the  j th  output  of  program  Q:  D,x...xD  - 

J « k 

is  a subset  of 

We  will  refer  to  the  set  of  security  policies  1^...,^  for  the  outputs 
of  a program  to  be  the  security  policy  I of  the  program. 


Definition.,  The  protection  mechanism  M is  sound  for  program  Q:  D x...xD  - 

1 k 

E1x...xEn  and  security  policy  I provided  for  each  output  y and  associated 

policy  Ij  *»  (x  ,...,x  \ there  exists  a program  M' : D x...xD  -»E'x...xE' 

' Jm  j i j _ 1 " n 

such  that 


Vxr..Vxk  M (x, 


•V  • Mj(xj 


,X  ). 

m 


Intuitively  the  meaning  of  the  security  policy  1^  for  an  output  variable 
is:  allow  the  output  to  depend  on  inputs  from  I.  but  not  on  any  inputs  which 


1 


lie  outside  of  I ^ . Therefore  the  protection  mechanism  M is  sound  for  program 
Q and  security  policy  I provided  that  for  each  j,  the  output  of  M only 
depends  on  inputs  from  1^.  We  create  a separate  security  policy  for  each 
output  variable  since  in  many  programs  the  ouputs  are  available  in  different 
environments . 

As  an  example,  consider  an  accounting  program,  TAX,  which  accepts  a tax- 
payer identification  file,  NAME-ADDR,  and  another  file  (or  set  of  files)  FIN 
describing  the  taxpayer's  financial  situation.  TAX  produces  two  outputs:  a 

bill  for  the  taxpayer  and  a completed  U.S.  1040  federal  tax  form.  The  tax- 
payer receives  both,  but  one  copy  of  the  bill  goes  to  the  author  of  the  TAX 
program.  TAX  is  to  be  confined  [Lampson]  from  disclosing  to  the  author  of 
TAX  any  information  private  to  the  taxpayer,  thus  the  bill  is  to  depend  only 
on  the  name  and  address  of  the  taxpayer,  but  not  on  his  financial  status. 

(We  assume  that  all  bills  for  the  use  of  TAX  are  for  the  same  amount.) 

Graphically  TAX  can  be  depicted 

NAME-ADDR  FIN 


output  y^  is  the  1040  form 

output  y is  the  bill  to 
the  taxpayer 


output  y^  is  a copy  of  the  taxpayer's 
bill  which  goes  to  the  author  of  TAX 


For  this  program  there  are  three  security  policies 


Ij  = (name-addr,  fin"), 
i2  - i3  - (name-addr). 
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Thus  y2  and  y3  are  to  depend  only  on  the  NAME -ADDR  file,  presumably  the  name 
and  address  of  the  taxpayer.  A sound  protection  mechanism  for  TAX  and  (1^,1  ) 

need  only  insure  that  neither  copy  of  the  bill  depends  on  Information  In  FIN. 

We  are  defining  a theory  of  security,  a subject  about  which  we  have  many 
intuitive  notions,  so  it  is  important  to  cover  the  very  large  class  of  secur- 
ity policies  that  one  might  reasonably  wish  to  enforce  using  a protection 
mechanism  in  a computer  system.  We  distinguish  between  'access  control'  policies 
which  specify  whether  a particular  access  operation  to  manipulate  an  object  con- 
taining information  is  permitted  and  the  more  general  'information  control' 
policies  which  restrict  the  use  of  information.  For  example,  enforcing  an  ac- 
cess control  policy  which  specifies  that  the  operation  READFILE (F)  cannot  be 
performed  on  the  object  F,  is  not  the  same  as  insuring  that  the  information  in 
F is  not  extracted.  There  may  be  a sequence  of  operations  (excluding  READFILE (F) ) 
which  in  effect  extracts  the  information  encoded  in  F.  Access  control  policies 
do  not  take  into  account  the  semantics  of  the  operations  permitted  and  prohibit- 
ed, and  thus  are  a proper  subset  of  the  information  control  policies. 

To  illustrate  the  difference  by  an  analogy,  consider  a painter  (analogous 
to  a program)  who  is  to  paint  a picture  (the  output)  without  green  paint.  This 
could  be  enforced  by  an  access  control  protection  mechanism  in  the  framework 
we  have  already  defined,  provided  all  the  green  paint  were  in  a known  set  of 

pots.  A sound  protection  mechanism  would  simply  not  allow  the  painter  to 
dip  his  brush  into  those  pots. 

However,  the  policy  of  forbidding  the  use  of  green  paint  is  not  an  access 
control  policy;  it  is  an  information  control  policy;  for  if  the  painter  is 
simultaneously  able  to  obtain  blue  and  yellow  paint,  he  can  mix  green  paint 
fnd  use  it,  violating  the  original  policy  to  be  enforced.  Most  protection 
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mechanisms  found  in  extant  programmed  systems,  particularly  operating  sys- 
tems, are  capable  of  enforcing  some  subset  of  the  access  control  policies 
and  not  thr  more  general  information  control  policies.  We  have  not  restrict- 
ed our  framework  to  access  control  policies,  though  we  could  alter  it  to  do 
so.  Instead  we  consider  a subset  of  the  larger  class  of  phenomena  --  the 
information  control  policies.  This  should  become  evident  in  the  presenta- 
tion of  the  surveillance  protection  mechanism  in  the  next  section. 


The  definition  of  sound  is  central  to  our  theory.  Is  it  correct?  More 
exactly,  does  the  mathematical  definition  of  sound  correspond  to  our  intui- 
tive notion  of  what  it  should  be?  Since  this  is  an  extra-mathematical  ques- 
tion, no  proof  can  be  found.  However,  we  believe  that  it  does  correpond  to 
our  intuitive  notion  provided  the  Observability  Postulate  is  valid.  The 
Observability  Postulate  states  that: 

'All  observable  attributes  of  a program  are  actual  outputs.' 

That  is,  all  ways  a program  can  communicate  information  to  an  outside  observer 
are  a priori  specified.  Two  examples  should  help  demonstrate  the  importance 
of  the  Observability  Postulate.  Consider  first  the  case  of  programs  which 
have  as  output  a single  computed  value,  available  outside  the  program  after 
termination  of  the  program's  execution.  In  this  case  the  Observability 
Postulate  is  easily  shown  to  be  violated:  The  following  program  M that  always 

outputs  '1'  would  appear  by  our  definition  to  be  sound  for  any  security  policy: 


J 
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( START  ) 

1 


1 

* 

iLoop 

[l(P 

fori 

steps 

C— - 

J 

t 

Glj 

£D 

1 

! 

( HALT  } 

Notf  that  th,  argument  that  M Is  sound  for  any  policy  la  based  on  the  fact 
that  H Is  a constant  function.  However,  we  can  simply  „bserve  the  running 
tlce  of  M and  conclude  whether  x,-0  or  x/0.  Ihls  failure  of  our  notion  of 
sound  stems  not  ftom  any  failure  In  our  definitions,  but  from  the  fact  that 

the  Observability  Postulate  was  violated.  M's  tunning  time  was  an  implicit 
output. 

The  above  example  is  compatible  with  our  framework  as  follows:  Let  us 

agree  that  progiams  will  output  not  just  computed  output  value(s),  but  a sum- 
mary of  their  entire  computational  history.  In  this  case,  they  will  also 
output  a single  variable  T (standing  for  'time1,  the  only  computational  history 
observable;  which  is  the  elapsed  real  time,  the  elapsed  compute  time  or  the 
number  of  steps  executed.  Now,  the  Observability  Postulate  is  no  longer  vio- 
lated. In  the  above  program  M is  no  longer  a constant  function:  the  length  of 

its  computation  depends  upon  X] ; hence,  M is  not  sound  for  the  security  policy 
I - (x2)  or  I - ( }*. 

{.  } denotes  the  empty  set. 
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By  the  nature  of  computer  systems,  there  are  a set  of  attributes  of 

computation  which  may  be  observed.  The  pattern  of  sound  waves  produced  by 

printer  hammers  hitting  a revolving  print  chain  may  be  sufficient  for  an 

eavesdropper  with  some  sound  equipment  to  detect  what  is  being  printed. 

Heat  radiation  of  computer  components  may  be  detectable.  The  pattern  of  tape 

movements  can  encode  information  visably  detectable  by  someone  in  the  computer 

room.  Even  patterns  of  a program's  use  of  operating  system  resources  may  be 

detectable  by  other  programs.  This,  too,  constitutes  a (potential)  output. 

Before  a sound  protection  mechanism  for  a program  can  be  defined,  all 

these  observables  must  be  specified  as  outputs  of  that  program.  In  the 

'worst  case',  the  program  will  be  defined  to  output  S_,...,S  where  S is 

0 m 0 

the  initial  state  of  the  program,  S is  the  final  state  and  S follows 

m i- 1 

directly  from  for  i-0,...,m-l.  What  comprises  the  state  has  been  determined 
by  what  a priori  is  known  to  be  observable. 

One  further  example  should  reinforce  the  subtlety  and  importance  of 
the  Observability  Postulate.  Let  our  programs  have  inputs  that  are  placed 
on  a linear  1 -way  read  only  tape  (automata  theorists  ’-ead  Turing  tape;  pjr 
automata  theorists  read  magnetic  tape)  with  the  read  head  initially  at  the 
leltmost  character: 


0 

[7 

X3 

L ■ 

• • • 

- 

A 


Consider  a protection  mechanism  M and  the  security  policy  I = (x2 We  assert 
that  M can  never  both  read  x2  and  also  be  sound  as  long  as  our  programs  output 
their  entire  computational  history.  This  follows  since  in  order  for  M to  get 


I 


i 
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to  tne  part  of  the  tape  where  is  stored  it  must  move  across  x1  . Even 
if  M does  not  look  at  1 , it  will  encode  the  length  of  x^  into  the 
computation  sequence  of  M;  hence,  M will  not  be  sound.  Now  we  see  that  our 
definition  of  sound  is  quite  correct  in  not  allowing  M to  be  sound.  However, 
suppose  that  we  wish  to  be  able  to  allow  inputs  to  be  on  linear  tapes;  how 
can  we  avoid  this  problem7  One  answer  is  to  add  a new  operation,  say,  tab(i). 
This  operation  in  one  step  causes  the  read  head  to  jump  directly  to  the  input 
part  of  the  tape  corresponding  to  x . Now  we  can  indeed  have  a protection 
mechanism  that  can  read  and  is  sound.  But  a new  problem  arises:  is  the 

Observability  Postulate  still  valid?  Perhaps  tab(i)  takes  time  dependent  on 
the  length  of  Xj,...,x.  ,,  ana  moreover  perhaps  this  time  is  observable. 

This  is  the  crux,  of  the  problem  and  there  seem  to  be  two  answers:  (1)  run 

tab(i)  so  that  it  uses  constant  time  or  (2)  apply  our  methods  recursively  to 
tab  (i) . 

In  general  we  can  always  attempt  to  male  the  problem  of  constructing  a 
protection  mechanism  easier  by  causing  execution  attributes  to  be  made  non 
observable,  i.e  , by  limiting  the  range  or  even  the  existence  of  outputs.  For 
instance  the  program  M in  the  first  example  is  sound  for  I <=  or  I «( 

if  it  is  run  in  a batch  environment  where  its  running  time  cannot  be  determined 
by  the  user  who  submitted  the  program  to  be  run. 

While  soundness  is  the  key  bridge  beeween  protection  mechanisms  and  secur- 
ity pol:  e«,  the  central  issue  is  not  just  to  construct  sound  protection  mech- 

anisms. The  protection  mechanism  that  always  outputs  some  fixed  violation 
notice  is  certainly  sound  --  it  is  also  useless.  (It’s  equivalent  to  pulling 
the  computei ' s plug  out  of  the  wall:)  We  are  therefore  led  to  consider  the 
concept  of  how  'complete'  a protection  mechanism  is. 


1 2 

De f Ini t ion . Suppose  that  M and  M are  protection  mechanisms  ior  the  same 

1 2 12 

program  Q and  policy  I.  Then  M is  as  complete  as  M (M  > M ) provided  ior 


all  inputs  a, 


if  (a)  / Q(a)*,  then  M2(a)  4 Q(a) 


Also  M1  is  more  complete  than  M“  (M1  > M2)  provided  M1  ^ M2  and  for  some  a, 

M ' (a)  = Q(a)  and  M2(a)  / Q(a). 

The  relation  ^ is  a partial  ordering  on  the  protection  mechanisms  lor 
a given  program  and  policy.  Also,  Ms  a practically  motivated  ord  'ing: 

Consider  a single  output  program  with  two  protection  mechanisms  M1  and  M2 . 

1 2 . 1 > 

M > M implies  that  M never  gives  a violation  notice  when  M does  not. 

] ~ 

This  implies  that  the  utility  of  M is  at  least  as  high  as  that  of  M , for 

one  is  only  interested  in  getting  non-violatirn  notices.  Note,  however,  that 
1 2 

if  M M for  a multi-output-variable  program  and  both  give  a violation 
notice  given  the  same  input  a,  that  violation  notice  may  not  be  for  the  same 
output  variable. 

We  can  show  how  to  ’join’  two  sound  protection  mechanisms  to  form  a 
new  sound  one  which  is  as  complete  as  each  of  the  other  two. 


1 2 

Dei  ..nition.  Suppose  that  M and  M are  protection  mechanisms  for  Q.  Define 

1 2 

to  be  the  protection  mechanism  M defined  by 


V input  a 


Q(a)  provided  3i,  Mi(a)  = Q(a),  i C (l ,2) 


^ ]M^(a)  otherwise 


The  key  property  of  union  is  that  if  either  M (a)  or  M2(a)  is  the  same  output 


it  ] _ . 1 

M (*)  r Q(fl)  if  there  is  any  output  M^(a)  ^ F. 


\ 


1 2 - 1 

as  Q(a),  then  so  is  the  union,  M U M <a).  Otherwise  since  both  M (a)  and 

2 - 12 
M (a)  include  at  least  one  violation  notice  so  does  M U M (a) . 

1 2 

Theorem  1 . Suppose  that  M and  M are  sound  protection  mechanisms  for  program 

1 2 

Q and  security  policy  I.  Then  M U M is  a sound  protection  mechanism  for  Q 
and  I.  Moreover,  M1  UM2  > m',  h'  U M2  > M2,  M1  U M2  > M2  U m'  and  M2  IJm'  > 
M1  U M2. 


Proof.  Immediate  from  the  definitions. 

We  can  easily  generalize  Theorem  1 tc  show  that  from  the  sound  protec- 
1 2 

tion  mechanisms  M ,M  ,...  we  can  form  one  all  encompassing  sound  protection 
1 2 i 

mechanism  M - M U M U ...  such  that  M > M . Indeed  it  can  easily  be  shown 
that  the  sound  protection  mechanisms  form  a lattice;  however,  we  shall  not 
need  this  observation  in  the  sequel. 

Theorem  2.  For  any  program  Q and  security  policy  I there  exists  a sound  protec- 
tion mechanism  M for  Q and  I such  that  M is  maximal.  That  is,  for  all  sound 
protection  mechanisms  M'  for  Q and  I.  M * M'. 

Proof.  Let  M a (m  ' | M * sound  for  Q and  1^  Let  M then  be 

NQi 

Then  as  in  Theorem  1 , M is  a sound  protection  mechanism  for  Q and  I.  Clearly, 
as  in  Theorem  1,  M > N for  any  sound  protection  mechanism  M;  hence,  M is  maximal. 

We  have  established  that  the  maximal  protection  mechanism  always  exists; 


however,  as  we  shall  show  in  Section  V,  they  cannot  always  be  constructed. 


Therefore  the  central  problem  is:  given  a program  Q and  a security  policy 

I,  find  a sound  protection  mechanism  M that  is  as  'high'  as  possible  under 
the  completeness  ordering.  In  the  next  two  sections  two  protection  mechanisms 
are  presented.  Later  in  Section  V these  and  other  mechanisms  are  compared 
under  the  > ordering. 


III.  SURVEILLANCE  PROTECTION  MECHANISM 

This  section  both  illustrates  a new  protection  mechanism  and  the  frame- 
work developed  in  the  preceding  section.  In  order  to  define  this  mechanism 
we  will  first  restrict  our  programs  to  be  flowcharts  with  a single  output. 

We  will  then  show  how  to  assign  to  each  flowchart  and  security  policy  a pro- 
tection mechanism  called  the  surveillance  protection  mechanism.  This  protec- 
tion mechanism  is  then  proved  to  be  sound  in  Theorem  3. 

Definition.  A flowchart  F with  input  variables  x^ x^  program  variables 

v-|»...,v  and  output  variable  y is  a finite  connected  directed  graph  whose 
nodes  are  boxes  of  the  form: 


START  BOX: 

( START  ) 

i 

DECISION  BOX: 

FALSE  TRUE 

(B (w)  is  a predicate) 

ASSIGNMENT  BOX: 

A 

v *-  E (w) 

(E(w)  is  an  expression 
and  v is  a program  or 
output  variable) 

HALT  BOX: 

— A — 

( HALT  ) 

I 


1 

* 

I 

I I 


Since  we  are  concerned  with  executing  programs  expressed  as  flowcharts, 
we  must  assure  ourselves  that  the  Observability  Postulate  is  valid.  We  will 
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assume  that  each  flowchart  F defines  a program  Q as  follows: 


Q:  fhJx...xN  - OyJ  x N) 


k copies 


where  k is  the  number  of  input  variables  of  1 and  iNl  is  the  set  of  natural 
numbers  (i.e.  fN  = (o,l,...)). 

Suppose  now  that  a is  an  input  for  Q.  Then  Q(a)  is  a pair,  the  first 

component  of  which  is  the  computed  output  and  the  second  component  of  which  is 

*v 

the  number  of  steps  executed.  We  ascribe  to  the  flowchart  F the  usual  seman- 
tics: There  is  exactly  one  start  box;  execution  begins  there  by  initializing 

x to  a , and  r and  y to  0 and  0.  C is  defined  to  be  the  program  counter  of  F,  a 
variable  which  contains  the  name  of  the  next  box  to  be  executed.  C is  initi- 
alize! to  contain  the  successor  of  the  start  box.  Execution  then  follows  the 
logic  of  the  flowchart;  at  a decision  box  the  path  corresponding  to  the  predi- 
cate's truth  value  is  taken.  The  predicates  in  the  decision  boxes  and  the  ex- 
pressions in  assignments  are  assumed  to  be  interpreted  in  the  sense  of  schemata 
theory  [Manna  | ; however,  no  specific  assumptions  are  made  about  what  predicates 
and  expressions  are  allowed.  Note  that  inputs  do  not  get  assigned  during  a 
computation. 

A halt  box  is  executed  by  making  available  to  the  external  world  an  ordered 
pair  consisting  of  the  value  of  y and  the  number  of  steps  executed. 

'k'fc 

Definition.  Suppose  that  Q is  a flowchart  program.  Associate  with  each 


Therefore  we  will  be  encoding  running  time.  We  might  have  chosen  number  of 
page  faults,  kilowatt-hours  consumed,  or  the  sequence  of  boxes  executed.  How- 
ever, wc  have  arbitrarily  selected  running  time  as  a representative  attribute 
oi  execution  that  is  observable. 


'flowchart  program  Q'  is  a shorthand  for  'flowchart  that  defines  the  pro- 
gram Q'  . 


L 


variable  v of  Q (input,  program,  output)  a new  boolean  valued 


variable  v called  the  surveillance  variable  of  v.  Suppose  further  that  I is 


Then  the  surveillance  protection  mechanism  M cor 


some  security  policy  for  Q 
responding  to  Q and  I is  the  flowchart  program  that  is  constructed  as  follow 


The  surveillance  variables  are  program  variables  of  M;  the  input,  program 


and  output  variables  of  Q have  the  same  lole  in  M.  M follows  from  Q by  the 


following  transformations 


1.  Insert  directly  after  the  START  box  assignments  that  set  v to  true 


2.  Replace  the  assignment  box  in  Q 


by  the  following 


FALSE 


A is  a new  symbol 


v *- 

it 

A 

1 

> 

v *- 

true 
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3.  Replace  the  decision  box  in  Q 


by  the  following 

JL 


Where  a flowchart  program  Q has  a range  (hs|  X ) , the  surveillance  pro- 
tection mechanism  for  that  flowchart  and  any  security  policy  has  a range 
(([y|  U (a))  X [K] ) • The  surveillance  mechanism  can  produce  a computed  output 
A,  which  can  be  called  the  'null  output'.  A violation  notice  for  the  surveil- 
lance mechanism  is  of  the  form  (A, i)  where  i € 1>4- 

Theorem  3.  If  M is  the  surveillance  protection  mechanism  for  the  flowchart 
program  Q and  security  policy  I,  then  M is  sound  for  Q and  I. 

A detailed  proof  is  omitted.  However,  an  easy  induction  argument  shows 
that  no  input  variable  v not  in  I is  ever  used  in  any  assignment  or  decision 
box  that  is  executed.  In  order  to  show  that  M is  sound  we  need  only  show  it 
is  equal  to  M'  where  M'  is  the  same  flowchart  as  M except  that  all  occurrences 
of  v not  in  I are  replaced  by  some  new  'dummy'  variable. 

In  order  to  illustrate  the  surveillance  protection  mechanism,  consider 
the  flowchart  program  : 
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START 


FALSE  X,.nX  TRUK 


T 

loop  a for  10  steps 

zn 


rr^r 


where  A is  some  computation  that  loops  for  some  large,  but  bounded  number  of 
steps.  Now  Q1^)  always  halts  with  y=1  ; however,  Q1  (x] ) = (l,n)  where  n is 
the  number  of  steps  executed  in  computing  Q1 (Xj ) clearly  depends  on  Xj  . Now 
let  us  consider  the  surveillance  protection  mechanism  for  and  the  secur- 


O*  ] 

. Then  M is 


FALSE 


( START 

< 

fel_l 

true 

L 

|y-  i 

'a  Ise] 

j 

< s 

y «-  A 


For  any  Xj,  M (x^  - (A, 5).  That  output  which  is  a violation  notice  indicating 
that  five  steps  were  executed,  is  independent  of  x1 . Thus  the  surveillance 


Recall  that  ^ } is  the  empty  set  indicating  that  the  computed  output  should 
rely  on  no  input  variables. 
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protection  mechanism  M always  outputs  the  same  answer  in  the  same  time  and 
theie  is  no  way  to  infer  from  the  output  of  M1  anything  about  the  value  of  in- 
put x ( . 

A pertinent  question  is:  how  can  one  implement  the  surveillance  protec- 

tion mechanism?  First,  the  surveillance  protection  mechanism  could  be  imple- 
mented as  part  of  an  interpreter.  Since  surveillance  variables  are  boolean 
valued,  this  would  use  only  a fairly  small  amount  of  space,  However,  the 
time  required  would  likely  be  large.  Second,  the  surveillance  protection  mech- 
anism could  be  implemented  as  part  of  a compiler.  One  could  have  a compiler 
generate  either  in  line  code  or  procedure  calls  to  update  and  test  the  surveil- 
lance variables  as  required.  It  is  likely  that  such  an  implementation  would 
execute  more  rapidly  than  the  interpreted  version.  Third,  the  surveillance 
protection  mechanism  could  be  implemented  in  hardware.  Each  boolean  surveil- 
lance variable  could  easily  be  represented  in  microcode  at  the  cost  of  one  bit 
per  variable. 

Fourth,  a new  protection  mechanism  functionally  equivalent  to  the  surveil- 
lance  mechanism  could  be  defined.  It  would  be  in  the  form  of  a compiler  which 
mapped  a program  and  a security  policy  into  a new  program  which  would  be  iden- 
tical to  the  surveillance  mechanism  for  that  program  with  all  computation  on 
surveillance  variables  evaluated  at  compile  time  and  thus  removed.  The  example 
program  would  be  mapped  to 


At  the  cost  of  possibly  generating  programs  larger  than  the  original  flowchart 


1 


programs  the  compiler  mechanism  could  allow  specification  of  security  policies 
to  be  postponed  at  the  time  of  program  invocation. 


i 
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IV.  HIGH  WATER  MARK  PROTECTION  MECHANISM 

In  the  last  section  the  surveillance  protect  ion  mechanism  was  presented; 
here  we  will  present  a second  protection  mechanism  called  the  high  water  mark 
protection  mechanism.  It  is  essentially  the  basis  for  some  government,  par- 
ticularly military,  information  systems;  it  is  also  an  abstraction  of  the  pro- 
tection mechanism  used  in  the  ADLPT-50  operating  system  described  in  [Weissman 
Hie  high  water  mark  protection  is  included  here  for  two  reasons:  (i)  the  fact 

that  we  can  represent  it  demonstrates  the  power  of  our  framework;  (ii)  it  is 
both  sound  and  unsound!  The  reason  for  the  latter  requires  some  further 
explanation  that  depends  on  the  Observability  Postulate. 

The  high  water  mark  mechanism  is  sound  only  in  the  case  that  the  observ- 
ables do  not  include  certain  attributes  of  the  computational  history  of  pro- 
grams. If  flowchart  programs  output  their  history,  for  example  their  running 
time  as  in  section  III,  then  the  high  water  mark  protection  mechanism  is  un- 
sound. Essentially  it  is  unsound  since  it  cannot  detect  that  a program  is 
leaking  information  by  varying  the  run  time  (as  we  will  later  show). 

On  the  other  hand,  suppose  that  we  modify  the  definition  of  flowchart  programs 
so  that  they  only  output  their  computed  output  variable  values.  Then  wr  can 
prove  that  the  high  water  mark  protection  mechanism  is  sound.  It  is  interest- 
ing to  note  that  our  framework  is  general  enough  to  allow  a mechanism  to  be 
both  sound  and  unsound  under  varying  specifications  of  observables. 

In  order  to  define  the  high  water  mark  protection  mechanism,  let  Q be  a 
flowchart  program  and  let  I be  a security  policy  (for  the  moment  we  will  not 
specify  whether  or  not  Q outputs  its  computational  history  as  well  as  its 
computed  output  variable''.  We  further  assume  that  we  are  given  a set  F 
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linearly  ordered  by  > and  a function  FQ  from  the  variables  of  the  flowchart 
Q to  the  set  F.  We  also  assume  that  there  exists  an  element  p in  F such  that 
for  any  v in  I and  any  w not  in  I, 

Fq(w)  > p :>  Fq(v)*. 

We  intuitively  interpret  this  as  follows: 

1.  F is  a set  of  'classifications'  such  as  'top  secret',  'secret', 
cont ident ia 1 ' , 'public'  which  are  ordered  so  that 

top  secret  > secret  > confidential  ^ public. 


2.  Initially  all  the  variables  in  a security  policy  I are  given  some 
classification  equal  to  or  lower  than  p;  all  other  variables  are 
given  some  classification  higher  than  p. 

As  in  the  construction  of  the  surveillance  protection  mechanism  we  associate 
with  each  variable  v of  Q a new  variable  v:  v has  values  in  F.  The  high 

water  mark  protection  mechanism  M is  constructed  by  the  following  local  trans 
formations  on  Q: 


1 • After  the  START  box  initialize  all  variables  v to  FQ(v). 
2.  Replace  the  assignment  box 

1 

v - E(w  , . . . ,w  ) 

i n 

by 


a^b  if  a > b or  a * b, 


s 


the  decision  box 


FALSE 


where  C is  the  variable  which  we  associate  with  the  program  counter 


4.  Replace  any  HALT  box  by 


TRUE 


FALSE 


where  A 's  the  null  output  value  introduced  earlier 


Theorem  4 . When  flowchart  programs  only  output  their  computed  output  variables 


then  the  high  water  mark  program  mechanism  is  sound 


maximum  under  the  order  > 


By  computed  output  variables  we  mean  those  explicitly  assigned  in  the  program 
not  those  like  running  time. 


* A | , 

v *-  WjU. . 

A A-* 

. Uw  Uv 

n 

j 

V - E(Wj , 

‘ ' ‘ ,Wn} 

A detailed  proof  is  omitted.  The  idea  of  the  proof  is  contained  in  the 
name  'high  water  mark1.  The  sets  v simply  keep  track  of  all  assignments  to 
v.  Note  in  the  assignment  v - f(w),  is  replaced  by  v and  w;  thus,  the  sets 
v ere  ’monotone’ : once  an  element  is  placed  into  them  it  must  remain  there. 

Finally  * violation  notice  (i.e.  A)  is  *iven  if  either  the  output  y or  the 
program  counter  contains  any  a € F which  is  of  higher  classification  than  p 
when  the  hflit  box  is  executed. 


In  contrast  to  Theorem  4 we  can  see  that  the  high  water  mark  protection 

mechanism  is  unsound  when  programs  output  their  running  time.  It  suffices  t< 

again  consider  the  following  program  0: 

( START  ") 


FALSE 


The  high  water  mark  protection  mechanism  M for  Q always  outputs  a violation 
notice  in  the  form  (A,i)  However,  the  length  of  the  computation  sequence  of 

M depends  directly  on  x,  : if  X]  - 0 it  is  4 ; if  X]  ft  0 it  is  103  + 4.  There 
tore,  in  this  case  the  high  water  mark  protection  mechanism  is  unsound. 

W stated  earlier  chat  the  Observability  Postulate  must  always  be  valid 
all  potential  outputs  of  a program  must  be  known.  This  discussion  provides 
one  illustration  of  a protection  mechanism  which  is  ineffective  or  unsound 
when  those  observables  are  of  a certain  class,  i.e.  running  time. 


V.  COMPARISON  OF  PROTECTION  MECHANISMS 

In  the  last  two  sections  the  surveillance  and  high  water  mark  protection 
mechanisms  were  presented  and  both  were  shown  to  be  sound  under  the  assumption 
that  programs  output  only  their  final  states.  As  noted  earlier,  sound  is  only 
part  of  the  story;  here  their  ordering  with  respect  to  completeness  is  con- 
sidered. While  soundness  is  all  or  none  we  will  see  that  with  respect  to 
completeness  there  is  indeed  a spectrum  of  possible  values. 

First  let  us  consider  the  surveillance  and  high  water  mark  protection  mech  - 
anisms.  In  order  to  make  this  comparison  meaningful  we  assume  -*s  before  that 

S 

programs  only  output  their  computed  values.  Suppose  that  M is  the  surveil- 

M 

lance  protection  mechanism  for  some  flowchart  Q and  security  policy  I and  M 

is  the  high  water  mark  protection  mechanism  for  Q and  I.  It  is  easy  to  see 
S H 

that  M > M is  always  true.  The  following  simple  flowchart  and  the  policy 
{xj}  shows  that  MS>  MH  is  possible: 


5 H 

In  this  case  M always  outputs  the  value  of  y,  but  M outputs  A.  Intuitively 

surveillance  is  better  here  since  it  allows  'forgetting'  while  high  water  mark 

does  not.  A more  impressive  example  of  forgetting  is  the  following: 

Suppose  that  during  a program  Q's  computation  it  must  use  a block 
of  memory  that  earlier  held  'sensitive  data'.  Surveillance  will  al- 
low Q(a)  (a  = the  input  value),  provided  Q correctly  'zeroes'  out 
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the  block  of  memory;  the  high  water  mark  mechanism  will  never  out- 
put Q(a) , even  after  this  zeroing. 

^ skeptical  reader  may  reply  that  this  example  is  artificial.  Why  not  just  re- 
write Q so  that  no  unneeded  assignments  are  performed?  But  consider  the  case 
of  a program  where  early  in  the  program  a variable  is  assigned  a value  which 
is  never  subsequently  used  before  the  variable  is  reassigned.  This  is  indeed 
reasonable:  often  in  software  that  value  would  have  been  used  had  the  inputs 

been  different. 

While  surveillance  is  more  complete  than  high  water  dark  it  is  not  maximal, 
i.e.  it  is  not  the  mechanism  that  produces  the  fewest  violation  notices.  In 
order  to  see  this  consider  the  following  program  Q: 

( START  ) 


« 
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It  is  easy  to  see  that  M'  is  sound  for  Q and  I.  Since  M'  > M we  see  that  the 
surveillance  protection  mechanism  is  not  maximal. 

The  reason  that  the  surveillance  protection  mechanism  performed  poorly 
on  is  that  once  we  branched  on  x^  there  was  no  way  for  surveillance  to  de- 
tect that  the  assignment  to  y was  independent  of  x^ . For  the  remaining  part 
of  this  section  we  will  investigate  how  to  modify  surveillance  so  as  to  make 

it  more  complete.  We  will  continue  to  assume  that  programs  only  output  ex- 
plicitly computed  values.  This  is  done  only  for  definiteness;  whether  or  not 

programs  also  output  their  running  time  or  any  other  attribute  makes  no  dif- 

ference in  thr:  following  analysis.  . 

As  a step  in  the  direction  of  improving  surveillance  suppose  that  we  modi- 
fied it  so  that  it  could  detect  flowchart  occurrences  of  the  form: 


i 


For  these  'i^  then  else ' constructs  could  we  make  all  future  computations  inde- 
pendent of  whether  the  then  or  the  else  path  was  taken  so  that  the  resulting 
protection  mechanism  is  still  sound?  The  answer  is  yes  and  is  demonstrated  by 
looking  first  at  the  example  i^f  then  else  of  Q: 


TRUE  / \ FALSE 


f 


Clearly,  the  above  is  functionally  equivalent  to 


where  f(x)  «*  _if  x ■ 1 then  1 else  2,  Let  us  transform  Q,  into  Q 


START 


Now  the  surveillance  protection  mechanism  for  Q'  and  I 


This  example  is  just  an  instance  of  a general  way  to  generate  many  dif 


ferent  protection  mechanisms:  Given  a program  Q transform  it  to  Q'  where  Q 


and  Q'  are  functionally  equivalent.  Then  apply  the  surveillance  protection 


mechanism  to  Q'  to  yield  a sound  protection  mechanism  for  Q.  The  above  ' if 


then  else1  transform  is  but  one  of  many.  For  instance,  ve  could  create  a 


for  loop*  transform  that  operates  on 


FALSE 


in  a way  analogous  to  the  ^jf  then  else  transfoitn.  Indeed  transforms  can  be 


created  for  all  single  entry  and  single  exit  structures 


Is  the  application  of  such  transformations  always  advisable?  Unfortunately 


the  inswer  is  no.  Consider  the  flowchart  program  Q 


be  the  security  policy  again.  Let  M be  the  surveillance  protec 


tion  mechanism  for  Q and  I;  also  let  M'  be  the  protection  mechanism  that  cor 


responds  to  the  then  e lse  transform  on  Q.  Clearly  since  M'  is  the  surveil 


lance  protection  mechanism  for  the  following  program 


START 


M'  always  outputs  A.  On  the  other  hand,  M outputs  1 provided  x = 1;  hence 


Thus,  the  danger  is  that  since  one  does  not  know  which  branch  was 


taken  one  mus*  assume  the  worst  case 


In  summary,  whether  to  apply  a transform  or  not  is  not  a clearcut  decision 


The  optimal  way  to  do  this  is  yet  unclear.  Indeed  we  can  prove  that  there  is 


no  effective  way  to  get  the  maximal  protection  mechanism 


Theorem  5.  Given  a flowchart  program  Q and  a security  policy  I it  is  not  ef 


fectively  decidable  if  M is  sound  and  maximal  for  Q and  I 


Proof.  Consider  the  following  program  Q and  the  security  policy  I that  is  the 


empty  set 


START  ) 


FALSE 


HALT 


Let  M be  the  maximal  protection  mechanism.  We  assume  that  A(x)  is  the  result 
of  some  arbitrary  total  function  with  A(0)  - 0.  Now  clearly  M(0)  ■ 1 or  A. 

We  now  claim  that 


Since  I is  empty,  M must  be  a constant  function, 
always  equal  to  1 is  clearly  maximal.  Now  assume 
that  M(0)  / 1.  Clearly,  M(b)  - 2 or  A.  Incase  M( 


M cannot  be  constant 


hence,  (1)  is  true 


Now  (1)  shows  that  if  we  can  effectively  construct  M,  thei 
tively  determine  whether  or  not  Vx  A(x)  - 0;  this,  however,  is 


The  fact  that  the  maximal  protection  mechanism  is  not  effectively  construe 
cible  should  be  contrasted  with  a similar  result  from  capability  theory 
Harrison  . Essentially  it  has  been  shown  that  one  cannot  effectively  deter- 
mine if  a program  will  ever  make  an  'illegal  access'.  This  results  from  the 
fact  that  it  is  impossible  to  a priori  determine  which  execution  sequence  a 
Program  will  take.  In  a sense,  therefore,  one  cannot  determine  statically 


(or  at  compile-time)  whether  or  not  a program  will  behave  properly.  On  the 
other  hand,  Theorem  5 demonstrates  that  it  is  impossible  to  determine  whether 
or  not  a program  has  obtained  'illegal  information'  even  if  the  exact  execu- 
tion sequence  is  known.  (Recall  protection  mechanisms  can  be  completely 
dynamic . ) 

VI.  PROTECTION  MECHANISMS  EXTENSIONS 


I 


The  surveillance  protection  mechanism  for  flowchart  programs  is  not  suf- 
ficient for  practical  computation.  If  possible,  it  should  be  extended  to  more 
complex  programs:  programs  that  allow  procedures,  pointer  variables,  and 

parallelism  are  possible  candidates.  Some  of  these  extensions,  as  indicated 
in  Sectio.i  V,  will  be  straightforward.  Others,  however,  may  be  difficult. 

We  wish  to  discuss  a simple  example  of  the  difficulty  of  correctly  extend- 
ing the  surveillance  mechanism.  Hopefully  this  example  will  show  some  of  the 
subtleties  of  the  area  of  security  enforcement. 

As  in  Section  IV  we  will  for  the  rest  of  this  section  assume  that  pro- 
grams only  output  their  explicitly  computed  outputs.  It  is  under  this 
seemingly  simplifying  assumption  that  we  will  present  an  example  of  the 
difficulty  of  extensions  to  the  surveillance  mechanism. 

A reasonable  extension  to  the  surveillance  method  is  the  following:  Sup- 

pose that  R is  a single  entry  and  single  exit  part  of  a larger  flowchart;  for 
example,  R is 


'1 


I 


The  rationale  here  is  that  since  R i*  single  entry  and  single  exit  soundness 
can  only  be  violated  by  executing  the  assignment;  if  the  assignment  is  not 
executed,  then  there  seems  to  be  no  way  to  ’remember'  which  branch  of  the  deci- 
sion box  was  taken.  The  claim  would  then  be  that  this  method  is  sound.  This 

method  is  attractive  since  it  is  higher  under  the  > ordering  than  the  surveil- 

★ 

lance  method.  Unfortunately,  this  extension  is  not  sound.  In  order  to  see 
this  consider  the  program  Q and  the  security  policy  I “ (^2)  w^ere  Q is: 

It  is  not  sound  even  in  the  presence  of  our  assumption  that  only  explicitly 
computed  values  are  output. 

K 


START 


FALSE 


HALT 


The  region  inside  the  dotted  lines  is  R.  The  surveillance  protection  mechanism 


for  Q and  I always  outputs  A.  On  the  other  hand,  the  extension  yields  a pro 


gram  that  outputs  A if  x.  = 1;  otherwise,  it  outputs  1.  Clearly,  this  is  not 


sound 


Intuitively  the  above  unsound  extension  overlooks  what  one  might  call  a 


negative  inference'.  The  extension  operates  fine  when  we  explicitly  set 


it  fails  when  we  do  nothing  to  y after  testing  x 


y to  2 after  testing  x 


A classic  negative  inference  is  due  to  A.  C.  Doyle  [Doyle] 


Holmes:  "Then  there  was  the  curious  incident  of  the  dog  in  the  nighttime 


The  dog  did  nothing  in  the  nighttime 


Watson 


Holmes:  "That  was  the  curious  incident 


f 


I 


I 


-34- 


VII.  CONCLUSIONS 

The  security  area  currently  lacks  unity  in  its  basic  definitions  and 
terminology.  A contribution  of  this  work  is  the  isolation  and  precise  state- 
ment of  the  key  questions  and  concepts  needed  in  any  theory  of  security.  It 
appears  to  us  that  the  following  questions  are  central  to  any  such  theory: 

1 . What  is  to  be  enforced? 

2.  What  is  to  do  the  enforcing? 

3.  Does  it  do  the  enforcing? 

4.  If  it  does,  then  how  well  dees  it  do  the  enforcing? 

5.  What  assumptions,  if  any,  are  made  in  answer  (3)? 

These  questions  are  expressed  precisely  as  follows  in  our  theory: 

I1.  What  is  the  security  policy? 

2'.  What  is  the  protection  mechanism? 

3'.  Is  the  protection  mechanism  sound? 

4'.  How  complete  is  the  protection  mechanism? 

5’.  Does  the  observability  postulate  hold? 

Not  only  are  these  the  key  questions  but  our  framework  is  general.  It  is  not 
biased  toward  any  particular  solution  for  providing  security.  For  example  it 
can  be  used  to  model  capability  systems  as  well  as  surveillance. 
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